arm: Allow TLS access with -mslow-flash-data#65
Open
jerome-pouiller wants to merge 1 commit intozephyrproject-rtos:zephyr-gcc-14.3.0from
Open
arm: Allow TLS access with -mslow-flash-data#65jerome-pouiller wants to merge 1 commit intozephyrproject-rtos:zephyr-gcc-14.3.0from
jerome-pouiller wants to merge 1 commit intozephyrproject-rtos:zephyr-gcc-14.3.0from
Conversation
jerome-pouiller
force-pushed
the
improve-mslow-data-path
branch
2 times, most recently
from
76d8400 to
d53d5f0
Compare
jerome-pouiller
force-pushed
the
improve-mslow-data-path
branch
from
d53d5f0 to
a98306e
Compare
keith-packard
approved these changes
Jan 21, 2026
keith-packard
left a comment
keith-packard
left a comment
There was a problem hiding this comment.
This seems completely reasonable; the -mslow-flash-data documentation says "literal load is minimized for better performance", and as TLS offsets cannot be relocated any other way, then the compiler should continue to use literal loads for them. At least until someone goes through the work of defining TLS relocations within instructions.
Some chips (such as SiWx917 from Silicon Labs) have slow data bus access. The -mslow-flash-data option generates appropriate code for these chips by disabling literal pools. However, the current implementation completely prevents TLS (Thread Local Storage) variables from working, since ARM does not provide relocations to encode TLS variables directly into instructions - they require literal pools. This change relaxes the -mslow-flash-data constraint to allow literal pools specifically for TLS accesses. While this results in slower TLS access (hence a warning is emitted), it is preferable to a hard error that prevents TLS usage entirely. With -mpure-code, literal pools remain completely disabled and TLS access still results in an error. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
jerome-pouiller
force-pushed
the
improve-mslow-data-path
branch
from
a98306e to
e354a69
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some chips (such as SiWx917 from Silicon Labs) have slow data bus access. The -mslow-flash-data option generates appropriate code for these chips by disabling literal pools. However, the current
implementation completely prevents TLS (Thread Local Storage) variables from working, since ARM does not provide relocations to encode TLS variables directly into instructions - they require literal pools.
This change relaxes the
-mslow-flash-dataconstraint to allow literal pools specifically for TLS accesses. While this results in slower TLS access (hence a warning is emitted), it is preferable to a hard error that prevents TLS usage entirely.With
-mpure-code, literal pools remain completely disabled and TLS access still results in an error.Few notes:
I wrote this patch for chips with very slow access to the data. However, I also tested
-mslow-flash-dataon chips not impacted by the issue and I have also seen 5-10% of performances improvements on these chips. Generalisation of this flag is out of the scope of this PR, but it is worth to be mentioned.I believe this patch could be accepted by the upstream. I am waiting for comment from Zephyr community before to submit it.